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Abstract 

This  paper  presents  issues  related  to  poliey-based  eomputing  in  a  serviee-oriented 
arehiteeture  (SOA)  for  network-centrie  warfare.  Service-oriented  computing  and  its 
associated  architecture  represent  a  new  paradigm  of  computing  and  numerous  issues  need 
to  be  addressed.  One  of  important  issues  is  distributed  policy  computing.  Issues  such  as 
policy  specification,  analysis,  enforcement,  synchronization,  and  communication  are  all 
related. 

Keywords:  Service-oriented  architecture,  service-oriented  computing,  enterprise  C2 
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1.  Introduction 

DoD  is  moving  into  GIG-based  service-oriented  network-centric  policy-based  enterprise 
computing.  These  new  C2  systems  will  be  drastically  different  from  the  traditional  C2 
systems  due  to  their 

•  Network-centric  nature; 

•  Service-oriented  architecture  (SOA)  and  associated  the  Service-Oriented 
Computing  (SOC); 

•  Policy-based  computing. 

Specifically,  network-centric  operation  means  that  each  C2  system  must  be  network 
ready,  and  must  be  able  to  interconnect  and  interoperate  with  other  C2  systems.  The  SOA 
adds  another  new  dimension  to  this  problem  as  SOC  is  fundamentally  different  from 
traditional  procedural  programming  as  well  as  the  00  computing.  The  requirement  that 
future  C2  systems  will  support  policy-based  computing  adds  another  complexity  to  these 
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challenges.  The  teehnology  for  policy-based  computing  is  at  the  development  stage  only 
and  it  will  take  years  before  the  teehnology  is  mature  enough  to  be  applied. 

This  paper  addresses  the  impact  of  SOA  on  modern  network-centric  enterprise  and 
policy-based  C2  systems.  Network-centric  operation  is  already  a  difficult  issue,  but  SOA 
involves  additional  issues  sueh  as  C2  poliey  speeifications,  V&V  and  enforeement.  In  an 
SOA  system,  a  serviee  ean  be  discovered,  bound,  exeeuted,  and  verified  and  validated  at 
runtime  and  in  real-time,  and  the  entire  system  is  organized  as  a  loosely  eoupled  system 
of  serviees.  While  this  kind  of  loose  coupling  provides  flexibility  and  adaptability,  it  is 
difficult  to  enforce  C2  polieies  in  sueh  a  network.  It  is  difficult  because  eaeh  eomputation 
unit  in  sueh  a  system  is  aetually  a  collection  of  services  possibly  composed  in  real  time 
and  at  runtime.  So,  how  can  one  enforce  C2  policies  in  such  an  environment  as  it  is  not 
known  what  service  will  be  used  before  applieation? 

While  eonsensus  exist  on  SOA-based  EC2  (Enterprise  C2)  systems  such  as 

•  Policies  must  be  formally  speeified  and  embedded  in  the  enterprise  C2  system 
because  these  polieies  may  be  dynamieally  eomposed  in  real  time  and  at  runtime; 

•  Policies  must  be  enforced  in  a  distributed  manner  involving  poliey 
synehronization  and  eoordination; 

•  Aetions  and  tasks  must  be  checked  and  enforeed  against  stated  C2  polieies  in  real 
time  and  at  runtime. 

However,  there  exist  differences  in  treating  policies  in  an  SOA.  This  paper  will  discuss 
those  issues. 

This  paper  is  organized  as  follows.  Section  2  briefly  overviews  SOC  paradigm;  section  3 
presents  poliey-based  computing;  section  4  shows  two  different  schools  of  thoughts,  both 
of  them  use  the  SOA  but  the  ways  they  treat  policies  are  drastically  different.  These  two 
approaehes  provide  a  good  comparison  and  contrast  of  policy-based  eomputing  in  an 
SOA. 

2.  Service-Oriented  Computing 

The  key  coneepts  of  SOC  are  as  follows  [9]; 

•  Eaeh  computing  unit  is  considered  as  a  service,  and  each  service  is  considered 
self-eontained  and  independent  of  other  services; 

•  A  serviee  publishes  its  interfaees  using  a  standard  language  WSDE; 

•  The  service  provider  registers  its  services  with  an  intermediate  broker  called 
UDDI  server. 

•  A  client  that  wishes  to  obtain  a  service  inquires  the  UDDI  server  and  requests 
speeific  services  that  it  needs; 

•  After  reeeiving  the  user  request,  the  UDDI  matehes  the  need  with  the  most 
appropriate  service  in  its  repository,  and  sends  the  ID  of  the  service  to  the  client; 
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•  The  client  then  makes  a  call  to  the  service  requesting  specific  kind  of  tasks  to  be 
performed;  and 

•  All  communications  among  all  parties  are  through  standard  protocols  such  as 
XML  and  SOAP 

SOC  is  fundamentally  different  from  00  Computing  (OOC)  even  though  SOC  evolves 
from  OOC.  SOC  may  looks  similar  in  many  ways  to  OOC,  but  it  is  a  different  computing 
paradigm.  In  the  past,  some  people  mistakenly  thought  that  OOC  is  not  much  different 
from  procedural  computing  because  procedural  languages  already  have  the  concept  of 
data  abstraction  and  procedure  calls.  They  did  not  realize  that  even  though  OOC  may 
look  similar  to  procedural  computing  in  numerous  ways,  the  fact  that  designers  think  in 
terms  of  classes  and  objects  fundamentally  changes  the  way  of  thinking.  And  from  the 
OOC,  many  new  concepts  emerge  such  as  UML,  design  patterns,  object  composition, 
dynamic  binding,  and  design  architecture. 

Similarly,  SOC  is  fundamentally  different  from  OOC  because  now  designers  are  thinking 
in  terms  of  services,  runtime  service  discovery  and  composition  [6] [7],  runtime  system 
re-composition,  and  runtime  system  verification  and  validations.  These  are  different  from 
the  OOC  concepts. 

Furthermore,  services  are  available  and  accessible  on-line.  A  user  or  a  software  agent  can 
use  runtime  search  to  discover  new  services.  A  user  may  not  need  to  buy  and  install, 
instead  just  call  and  use  the  service  remotely.  Software  upgrade  will  become  easier 
because  once  the  service  is  upgraded,  the  new  service  will  immediately  replace  all  the  old 
versions  instantly,  saving  significant  cost  of  un-installing  and  re-installing  software. 

The  SOC  also  has  a  significant  impact  on  the  system  structure  and  dependability  such  as 
system  reliability,  system  composition  (and  re-composition),  and  security.  These 
mechanisms  are  different  from  the  corresponding  OOC  mechanisms.  For  example, 
instead  of  static  composition  (with  dynamic  objects  and  dynamic  binding)  in  OOC,  SOC 
allows  dynamic  composition  in  real  time  and  at  runtime  using  services  just  discovered, 
and  with  knowledge  of  the  service  interface  only  [8] [14].  Because  multiple  new  services 
that  meet  the  same  specification  can  be  discovered,  SOC  also  needs  a  runtime  ranking, 
interoperability  evaluation,  testing,  and  selection  mechanisms.  In  case  of  system  failures, 
the  SOC  has  a  distributed  reconfiguration  [8][14],  and  such  protocol  is  different  from  the 
reconfiguration  protocol  in  00  software.  In  SOC,  a  faulty  service  can  be  easily  replaced 
by  another  standby  service  by  the  DRS  (Dynamic  Reconfiguration  Service),  and  the  DRS 
itself  is  also  a  service  that  can  be  monitored  and  replaced.  The  key  is  that  each  service  is 
independent  of  other  services,  and  thus  replacement  is  natural.  Only  the  affected  services 
will  be  removed  and  this  allows  mission-critical  applications  to  proceed  with  minimum 
interruption. 

This  will  be  difficult  to  achieve  in  OOC  because  the  replacement  code  must  be  developed 
and  put  into  the  place  via  dynamic  binding.  The  current  00  dynamic  binding  mechanism 
allows  methods  that  belong  to  a  family  of  classes  can  replace  each  other  at  runtime,  yet 
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SOC  allow  an  unrelated  serviee  to  replace  an  existing  service  as  long  as  the  new  service 
has  the  same  specification. 

The  SOA  is  robust  and  survivable  because  most  of  binding  is  done  at  runtime,  thus 
services  can  be  removed  and/or  added  to  the  service  pool  without  changing  the  overall 
architecture  and  protocols  among  all  the  parties.  If  a  service  is  removed  from  the  service 
pool,  the  UDDI  server  will  select  a  new  service  provider  at  runtime;  similarly  if  a  new 
service  wishes  to  join  the  service  pool,  it  simply  registers  its  services  with  the  UDDI 
server. 


•  Essentially,  SOC  will  change  the  whole  landscaping  in  system  and  software 
development  from  requirement  to  V&V.  Specifically,  in  the  requirement  stage, 
knowledge  of  existing  services  is  critical  as  reusability  will  be  the  key  enabler. 
Thus,  rather  than  construction  of  new  requirements,  reuse  of  existing 
requirements  including  existing  service  specifications  will  be  critical. 

•  In  the  design  stage,  the  loosely  coupled  SOA  allows  dynamic  composition, 
dynamic  re-composition,  and  dynamic  reconfiguration.  In  the  sense,  the  design  is 
never  completed  because  new  service  may  arrive  after  the  current  design  is 
completed,  and  the  new  service  may  replace  the  already  selected  services  at 
runtime  in  real  time. 

•  In  the  implementation  phase,  majority  of  work  will  be  composition  (or  linking) 
rather  than  code  development  as  services  will  be  reused. 

•  In  the  V&V  phase,  CV&V  (Collaborative  Verification  and  Validation) 
[10][11][13][18]  will  be  used  rather  than  IV&V  as  the  source  code  of  many 
services  may  not  be  available.  Service  specification  will  be  extensively  used 
because  often  a  service  customer  has  access  to  specification  and  URL  only,  no 
source  code  or  even  binary  code  would  be  available. 

Various  SOA  system  engineering  techniques  are  available,  including: 

•  Automated  completeness  and  consistency  checking  [15]. 

•  Verification  and  analysis  techniques  including  both  static  and  dynamic 
verification  techniques  [19]; 

•  Automated  state  model  generation  [20]; 

•  Formal  model  checking  [2]  [3]; 

•  Runtime  verification  and  constraint  checking  with  simulation  [16]; 

•  Automated  test  case  generation  [17]; 

•  Test  coverage  analysis  based  on  the  service  specification  and  risk  analysis; 

•  Automated  dependency  identification  and  analysis; 

•  Automated  concurrency  analysis;  and 

•  Autonomous  distributed  test  execution  via  remote  agents  [12]. 
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Acceptance  of  SOA  within  DOD 

SOC  has  recently  gained  acceptance  within  DOD.  Specifically,  two  important  projects, 
namely  NCES  and  GIG-ES  are  based  on  SOC.  Specifically,  NCES  has  the  following 
critical  services: 

•  Discovery; 

•  Messaging; 

•  Collaboration; 

•  Brokering; 

•  Storage; 

•  lA  (information  assurance)  and  Security; 

•  Domain  Name  Service  (DNS); 

•  Enterprise  service  management  (ESM);  and 

•  Mediation. 

And  GIG-ES  adds  the  additional  services: 

•  Command  and  control; 

•  Eocused  logistics; 

•  Battlespace  awareness; 

•  Eorce  applications; 

•  Protection; 

•  Expedient  and  cross-domain  COI  (Community  of  Interest)  including  business  and 
warfighting  COIs; 

•  Human  resource  management; 

•  Strategic  planning  and  budgeting; 

•  Accounting  and  finance; 

•  Eogistics;  and 

•  Acquisition. 

3,  Policy-based  Computing 

A  policy  is  a  statement  of  the  intent  of  the  controller  of  some  computing  resources, 
specifying  how  he  wants  them  to  be  used.  A  policy  allows  or  denies  subjects  (such  as 
processes)  that  satisfy  some  conditions  to  perform  designated  actions  on  objects  (such  as 
files)  [1].  The  common  pattern  of  a  policy  takes  the  form  of: 

{allow  I  deny  |  require}  {subject}  performs  {action}  on  {object}  when  {conditions} 

Policies  range  from  simple  (accept  users  with  correct  passwords)  to  complex  (reject  users 
who  read  a  file  three  times  over  the  past  24  hours).  A  policy-handling  system  must 
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provide  a  flexible  and  powerful  means  to  speeify  various  policies.  Runtime  mechanisms 
must  be  provided  as  well,  so  that  the  system  can  enforce  specified  policies.  Policies  are 
also  changeable,  which  requires  the  system  be  able  to  dynamically  revise  policies. 
Consequently,  policy  specification,  enforcement  and  revision  are  the  three  basic 
mechanisms  a  policy-handling  system  must  provide. 

Policy,  n.  1.  a  course  or  general  plan  of  action.  2.  a  contract  of  insurance  governing 

a  plan  of  action.  3.  the  rules  or  constraints  governing  a  general  plan  of  action. 

Within  the  context  of  the  EC2  the  term  policy  refers  to  the  set  of  rules  (constraints)  that 
govern  C2  actions  within  a  given  C2  policy  domain.  Specifically,  a  policy  is  a  statement 
of  the  intent  of  a  controller  of  some  resource  specifying  how  such  resources  are  to  be 
used.  In  an  SOA,  a  policy  will  be  interpreted  and  executed  in  real  time  at  runtime  to  meet 
the  agile  and  changing  requirements. 


Policy  Specification  Languages 

Policies  are  ubiquitous  in  most,  if  not  all,  computing  systems.  However,  one  might  not  be 
aware  of  their  existence,  because  most  policies  are  coded  into  a  system’s  implementation 
by  functional  requirements,  language  features,  and  design  decisions  [4][5].  For  example, 
if  a  policy  says,  “passwords  must  be  at  least  8  characters  long”,  there  must  exist  a 
segment  of  code  in  the  system  that  checks  the  length  of  passwords. 

This  traditional  approach  to  implementing  a  policy-handling  system  has  limitations: 

•  It  does  not  separate  policy  specification  from  policy  implementation. 

•  Policies  are  difficult  and  expensive  to  change.  Adding  new  policies  or  updating  / 
removing  existing  policies  requires  modifying  the  policies,  recompiling  and 
redeploying  these  policies  into  the  system. 

If  policy  specifications  and  implementations  are  separated,  any  change  of  policies  can  be 
easily  implemented  without  changing  the  architecture  of  the  system,  and  this  significantly 
simplifies  the  entire  process.  Policy  specification  languages  are  an  attempt  to  meet  the 
above  requirements.  A  policy  is  thus  a  binding  of  entities  and  their  attributes  to  specified 
actions.  What  entities,  attributes  and  actions  can  be  represented  depends  on  the  concrete 
system  in  which  policies  are  to  be  specified. 

Some  of  benefits  of  employing  policy  specification  languages  to  implement  a  policy¬ 
handling  system  are: 

•  Policy  specification  languages  enable  policies  to  be  defined,  independent  from  a 
concrete  system  implementation. 

•  Policy  specification  languages  are  to  be  interpreted  by  a  policy  engine  at  runtime, 
which  makes  dynamical  policy  changes  possible. 

•  Policy  specification  languages  formalize  the  intent  of  the  controller  into  a  form 
that  can  be  read  and  interpreted  by  systems. 
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•  Policy  specification  languages  are  high-level  languages,  which  makes  it  easy  to 
learn  and  use  by  policy  makers  who  are  normally  non-programmers. 

Policy-Based  Computing  in  GIG 

Poliey-based  eomputing  is  motivated  by  GIG  as  it  has  many  policy  specification  and 
enforcement  requirements: 

•  Policy-Based  Networking:  Various  network  operations  will  be  possible  but  they 
will  be  eontrolled  by  policies  in  an  EC2  SOA. 

•  Common  Open  Policy  Service:  this  is  a  query  and  response  protoeol  that  can  be 
used  to  exehange  poliey  information  between  a  poliey  server  and  its  elients. 

•  Routing  Protocol  Specification  Language:  this  allows  a  network  operator  to 
speeify  routing  policies  at  various  levels. 

•  Internet  Protocol  (IP)  Security  Policy:  this  is  a  repository-independent 
information  model  for  supporting  IP  security  policies. 

Poliey-based  eomputing  means  that  each  computing  unit  within  an  EC2  has  the  following 
eapabilities  or  rules: 

1 .  It  has  a  formal  and  self  consistent  set  of  C2  policies, 

2.  It  has  a  set  of  C2  policy  execution  processes  (meehanisms), 

3.  It  has  a  set  of  C2  process  performanee  measures  and  measurement  proeesses,  and 

4.  It  has  an  accountability  structure  governing  allocation  of  assets  required  in  and 
consumed  by  the  exeeution  of  any  given  poliey  or  set  of  policies 

In  an  EC2,  a  poliey  is  speeified  and  exeeuted  within  a  policy  domain  as  defined  below: 

Policy  Domain,  n.  1 .  a  region  of  policy  space  where  a  particular  set  of  policies  are 
applied  in  the  implementation  (exeeution)  of  one  or  more  plans  of  action  (POA) 

Within  the  eontext  of  an  EC2  enterprise,  there  are  many  poliey  domains,  organized 
aecording  to  the  extant  command  and  control  accountability  structure  (hierarchy).  The 
EC2  accountability  structure  defines  a  policy  tree  spanning  selected  aetivities  of  the  joint 
field  eombatant  commanders  up  through  the  President  of  the  Elnited  States.  This 
“nested”  set  of  interdependent  poliey  domains  eonstitutes  a  containment  hierarchy. 
Generally,  enterprise  poliey  trees  include  high-level  strategie,  mid-level  operational  and 
low-level  tactical  policy  domains. 

Another  important  feature  is  that  a  policy  in  an  EC2  SOA  must  be  exeeutable  as  polieies 
will  be  enforced  at  runtime  in  real  time,  and  thus  it  is  essential  policies  can  be  exeeuted  at 
runtime  and  in  real  time  to  enforce  their  eonstraints.  The  exeeution  capability  of  a  policy 
language  enables  numerous  tasks  that  were  not  possible  before,  ineluding  the  ability  to 

•  Simulate  the  effects  of  adding  new  or  modifying  existing  polieies  prior  to  their 
deployment  throughout  relevant  policy  domains,  and 
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•  Provide  a  formal  means  of  verification  and  validation  that  polieies  are  “correet” 
with  respect  to  quality  of  service  (QOS)  and  service  level  agreements  (SLA) 
established  for  their  respective  containment  domains  at  runtime  and  in  real  time. 


Policy  Enforcement  and  Operations 

A  policy  language  must  allow  policies  specified  to  be  enforced  either  statically  or  at 
runtime.  Both  static  and  runtime  policy  enforcement  follows  a  3-step  process: 

•  Policy  C&C  checking:  This  ensures  that  policies  specified  are  complete  with 
external  requirements  and  regulations,  as  well  as  consistent  with  each  other  before 
application  of  these  policies  to  evaluate  the  concerned  system.  Sample  security 
policies  can  be  Bell-LaPadular  security  policies  or  Chinese  Wall  security  policies. 

•  Embed  policies  with  the  system  specification:  Once  the  policies  specified  are 
determined  to  be  of  reasonable  quality,  the  policies  specified  using  PSEL  can  now 
be  embedded  into  the  system  specification  for  evaluation 

•  Evaluation  of  the  system  with  respect  to  policies  specified:  This  step  evaluates  the 
system  to  see  if  it  satisfies  the  policies  specified. 

Similarly,  a  policy  language  must  allow  policies  to  be  updated,  simulated,  and  analyzed 
in  real  time  and  at  runtime.  Also,  note  that  these  must  be  done  while  the  EC2  is  still 
running,  possibly  during  an  important  mission. 

4,  Different  Schools  of  Thoughts  on  SOA  for  Enterprise  C2  Systems 

One  school  of  thought  (we  label  it  School  A)  is  that  SOA  is  simply  an  implementation 
technology  just  like  other  programming  languages  or  design  techniques  such  as  OOC, 
and  thus  the  impact  of  SOA  to  EC2  is  limited  as  the  fundamental  C2  principles  remain 
the  same  regardless  of  the  implementation  technology  used.  In  this  way,  policies  can  be 
treated  as  static  XML  text.  It  is  the  role  of  some  NOW  policy  management  service  that 
creates,  publishes,  and  maintains  a  federation  of  policy  databases.  Eurthermore,  each 
enterprise  node  must  be  able  to  establish  and  maintain  its  own  set  of  local  policies  as  well 
as  be  aware  of  the  global  policies  under  which  it  must  comply.  As  a  consequence,  the 
NOW  policy  services  are  simultaneously  local  and  global.  V&V  is  first  and  foremost  a 
local  matter  (self-consistency),  and  secondarily  a  global  matter  (mutual  consistency). 
Resolution  of  local  and  global  policies  is  subjective  and  the  purview  of  enterprise 
managements.  Essentially,  policies  are  treated  as 

Policy  :=  {{Rules},  {Penalty  Eunctions} } 


Another  school  of  thoughts  (School  B)  believes  that  even  though  the  fundamental  C2 
principles  remain  the  same,  the  technology  used  can  have  a  drastic  impact  on  EC2.  While 
both  Schools  A  and  B  are  new,  they  have  different  opinions  on  the  following  issues: 

School  A  treats  policies  as  passive  entities  and  they  are  used  mainly  for  constraint 
checking  and  enforcement.  In  this  way,  the  C2  processes  used  to  implement  the  policies 


need  to  be  synehronized.  Furthermore,  because  C2  policies  are  mainly  static  objects,  the 
creation,  specification,  and  enforcement  will  be  easier  to  manage.  The  main  focus  is  on 
developing  the  generic  EC2  architecture  that  is  independent  of  the  implementation 
technology  and  can  use  a  hodgepodge  of  infrastructure  to  implement  EC2  if  necessary, 
including  a  mixture  of  traditional  C2  systems  and  SOA  C2  systems.  This  school 
maintains  that  the  EC2  architecture  remains  the  same  and  should  not  be  affected  by  any 
implementation  technology  such  as  SOA. 

School  B  treats  policies  as  active  services  that  will  be  called  in  real  time  to  perform 
enforcement.  In  this  way  policies  can  be  published,  disseminated,  executed,  and 
monitored  just  like  any  other  service  in  the  system.  While  the  new  school  also  ensures  the 
fundamental  EC2  principles  remain  the  same,  the  impact  of  SOA  can  be  immeasurable. 
In  fact,  the  changes  can  be  drastic  because  C2  policies  can  be  updated  and  validated  in 
real  time  and  at  runtime  to  give  decision  makers  and  warfighters  maximum  flexibility  for 
the  modern  agile  warfighting. 

School  A  treats  policies  as  passive  services  affecting  only  the  implementation,  not  the 
architecture  or  design.  This  school  thinks  that  frequent  changes  in  policies  create 
significant  overhead  such  as  synchronization  among  various  C2  processes,  changes  in 
action  plan  generation,  and  changes  in  asset  management.  These  changes  will  make  C2 
processes  complicated  and  thus  slow  down  C2  processing.  Eurthermore,  updating  C2 
policies  in  real-time  can  be  problematic  as  it  may  complicate  the  decision  process  as  C2 
policies  are  often  related  to  the  surrounding  context. 

School  B  considers  flexibility  and  adaptability  are  the  key  factors;  treating  C2  policies  as 
active  services  and  providing  the  flexibility  needed  in  the  modern  agile  warfighting.  The 
added  overhead  should  be  rather  minimal.  The  SOA  already  has  this  overhead  of  service 
interfaces:  publishing,  discovery,  composition,  execution,  verification,  and  monitoring, 
and  thus  treating  policies  as  active  services  should  not  increase  the  overhead  much, 
however,  the  benefits  of  treating  C2  policies  as  active  services  add  significant  flexibility 
to  warfighters  that  were  not  available  before. 


Policies  as  passive  objects 
(School  A) 

Policies  as  active  services  (School 
B) 

Policy 

Specification 

Policies  specified  as  data  such 
as  XML  files. 

Policies  specified  as  services 

Policy 

Enforcement 

Policies  will  be  enforced  by 
execution  services,  different 
enforcement  algorithms  and 
software  can  be  used. 

Policy  services  are  active  services 
that  can  perform  enforcements. 
Multiple  services  may  cooperate 
together  to  accomplish  service 
enforcement. 

Policy 

Overhead 

As  policies  are  treated  as  static 
objects,  the  overhead  of  policy 
is  the  overhead  of  accompanied 
computation  in  managing  and 
enforcement  of  policies. 

Policy  services  is  just  like  another 
services.  The  overhead  is  the 
added  complexity  of  activating 
policy  services  while  doing 
regular  computing. 
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Policy  Update 

Policy  can  be  updated  by 
updating  the  related  policy  files, 
and  possibly  policy  processing 
services  as  well. 

Policy  can  be  updated  by 
replacing  the  existing  policy 
service  by  a  new  policy  service. 

Policy  V&V 

Various  static  and  dynamic 
V&V  mechanisms  can  be  used, 
e.g.,  completeness  and 

consistency  checking,  and 
policy  simulation. 

Policy  V&V  will  be  equivalent  to 
service  V&V,  a  variety  of  static 
and  dynamic  V&V  techniques  can 
be  used  including  test  case 
generation,  simulation,  and 

runtime  monitoring. 

Policy 

Simulation 

Policy  can  be  simulated  by 
running  the  system  using  policy 
data. 

As  a  policy  service  is  just  another 
service  in  an  SOA,  policy 
simulation  can  be  carried  using 
any  SOA  simulation. 

Policy 

communication 

Two  systems  can  send  policies 
to  each  other  like  sending  a 
regular  electronic  message  as 
policies  are  treated  as  data. 

Two  systems  can  communicate 
their  policies  by  sending  service 
specifications  or  the  URL  of  the 
related  services. 

Policy 

synchronization 

Policy  synchronization  is 

needed  whenever  a  policy  is 
updated  or  the  system  is 
reconfigured.  Formal 

synchronization  protocols  need 
to  be  employed  to  ensure 
completeness  and  consistency. 

Policy  synchronization  is  needed 
whenever  a  policy  service  is 
updated  or  system  is  reconfigured. 
Policy  services  may  actively 
pursue  their  own  service 

synchronization  protocols. 

System 

Structure 

Enterprise  C2  systems  will  be 
organized  in  an  SOA,  but 
policies  will  be  treated  as 
objects  or  data  used  by  services. 

Enterprise  C2  systems  will  be 
organized  in  an  SOA-manner  and 
policy  services  will  be  treated  like 
a  regular  service. 

System 

Reconfiguration 

Systems  can  be  easily 

reconfigured  using  a  DRS 
(dynamic  reconfiguration 

service)  and  policy  files  need  to 
be  updated  to  ensure  that  new 
policies  are  consistent  with  the 
new  system  structure. 

System  can  be  easily  reconfigured 
using  a  DRS,  and  policy  services 
will  be  a  part  of  reconfiguration 
process. 

5,  Other  Consideration  Issues  and  Open  Issues 

What  is  the  likely  change  rate  of  policies?  Different  policies  are  likely  to  have  different 
change  rate.  Any  time  a  policy  is  updated,  the  C2  system  may  need  to  go  considerable 
changes,  e.g.,  the  C2  SOA  system  may  need  to  be  re-composed  to  fit  the  new 
requirements  of  the  updated  C2  policies.  Because  of  such  overhead,  it  is  important  that 
the  enterprise  C2  system  will  be  organized  in  a  hierarchical  manner,  and  thus  minimizing 
the  impact  of  the  change  once  C2  policies  are  updated. 
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The  EC2  SOA  still  face  many  open  problems  such  as 

•  A  formal  yet  easy  to  use  policy  specification  language  that  can  be  used  to  specify, 
analyze,  simulate  and  enforce  distributed  policies  in  an  EC2  SOA  federated 
systems; 

•  Distributed  policy  synchronization  and  enforcement;  and 

•  Policy  dependency  analysis  to  assist  real-time  policy  evolution; 

These  and  other  related  issues  must  be  addressed  before  policy-based  computing  can  be 
realized. 
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Features  and  Challenges  in  New  NC 
C2  Systems. 

■  Network-centric  nature 

■  Service-Oriented  architecture  (SOA)  and  associated 
the  Service-Oriented  Computing  (SOC) 

■  Policy-based  computing 

□  Policies  are  specified  as  a  part  of  the  system 

□  Policies  can  be  changed  and  updated  at  runtime  in  real 
time  during  warfighting 

■  These  features  distinguish  new  C2  systems 
from  the  traditional  C2  systems. 


Motivation 


■  Addressing  the  impact  of  SOA  on  modern  network-centric  enterprise 
and  policy-based  C2  systems. 

■  Network-centric  operation  is  already  a  difficult  issue,  but  SOA  involves 
additional  issues  such  as  C2  policy  specifications,  V&V  and 
enforcement. 

■  In  an  SOA  system,  a  service  can  be: 

□  Discovered,  bound,  executed,  verified  and  validated  at  runtime  and  in  real¬ 
time;  and 

□  The  entire  system  is  organized  as  a  loosely  coupled  system  of  services. 

While  this  kind  of  loose  coupling  provides  flexibility  and  adaptability,  it  is  difficult 
to  enforce  C2  policies  in  such  a  network  as  it  will  involve  policy  synchronization. 

■  Each  computation  unit  in  such  a  system  is  actually  a  collection  of 
services  possibly  composed  in  real  time  and  at  runtime.  So,  how  can 
one  enforce  C2  policies  in  such  an  environment  as  it  is  not  known  what 
service  will  be  used  before  application? 
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Consensus  on  SOA-based  EC2  Systems 


■  Policies  must  be  specified  and  embedded  in  the 
enterprise  C2  system  because  these  policies  may 
be  dynamically  composed  and  changed  in  real  time 
and  at  runtime; 

■  Policies  should  not  be  hard  coded  into  the  system  - 
this  will  make  changes  very  difficult  for  agile 
warfighitng; 

■  Policies  must  be  enforced  in  a  distributed  manner 
involving  policy  synchronization  and  coordination; 
and 

■  Actions  and  tasks  must  be  checked  and  enforced 
against  stated  C2  policies  in  real  time  and  at  runtime. 


Service-Oriented  Computing 

The  key  concepts  of  SOC  are  as  follows: 

■  Each  computing  unit  is  considered  as  a  service,  and  each 
service  is  considered  self-contained  and  independent  of  other 
services: 

■  A  service  publishes  its  interfaces  using  a  standard  language 
such  as  WSDL  or  OWL-S; 

■  The  service  provider  registers  its  services  with  an  intermediate 
broker  such  as  a  UDDI  server. 

■  A  client  that  wishes  to  obtain  a  service  inquires  the  UDDI  server 
and  requests  specific  services  that  it  needs; 

■  After  receiving  the  user  request,  the  UDDI  matches  the  need  with 
the  most  appropriate  service  in  its  repository,  and  sends  the  ID  of 
the  service  to  the  client; 

■  The  client  then  makes  a  call  to  the  service  requesting  specific 
kind  of  tasks  to  be  performed;  and 

■  All  communications  among  all  parties  are  through  standard 
protocols  such  as  XML  and  SOAP. 


Difference  between  SOC  &  OOC 


■  SOC  may  looks  similar  in  many  ways  to  OOC, 
but  it  is  a  different  computing  paradigm; 

■  Like  OOC  is  much  different  from  procedural 
computing,  SOC  is  fundamentally  different 
from  OOC; 

■  Designers  are  thinking  in  terms  of  services, 
runtime  service  discovery  and  composition, 
runtime  system  re-composition,  and  runtime 
system  verification  and  validations.  These  are 
different  from  the  OOC  concepts. 
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Difference  between  SOC  &  OOC 

(Continued) 


■  Services  are  available  and  accessible  on-line.  A 
user  or  a  software  agent  can  use  runtime  search  to 
discover  new  services.  A  user  may  not  need  to  buy 
and  install; 

■  SOC  also  has  a  significant  impact  on  the  system 
structure  and  dependability  such  as  system 
reliability,  system  composition  (and  re-composition), 
and  security;  and 

■  The  SOA  is  robust  and  survivable  because  most  of 
binding  is  done  at  runtime,  thus  services  can  be 
removed  and/or  added  to  the  service  pool  without 
changing  the  overall  architecture  and  protocols 
among  all  the  parties. 


SOA  Development  Process 

■  Essentially,  SOC  will  change  the  whole  landscaping  in  system 
and  software  development  from  requirement  to  V&V.  Specifically, 
in  the  requirement  stage,  knowledge  of  existing  services  is 
critical  as  reusability  will  be  the  key  enabler.  Thus,  rather  than 
construction  of  new  requirements,  reuse  of  existing  requirements 
including  existing  service  specifications  will  be  critical. 

■  In  the  design  stage,  the  loosely  coupled  SOA  allows  dynamic 
composition,  dynamic  re-composition,  and  dynamic 
reconfiguration.  In  the  sense,  the  design  is  never  completed 
because  new  service  may  arrive  after  the  current  design  is 
completed,  and  the  new  service  may  replace  the  already 
selected  services  at  runtime  in  real  time. 


SOA  Development  Process  (continued) 


■  In  the  implementation  phase,  majority  of  work  will 
be  composition  and  linking  rather  than  code 
development  as  services  will  be  reused. 

■  In  the  V&V  phase.  CV&V  (Collaborative  Verification 
and  Validation)  will  be  used  rather  than  IV&V  as  the 
source  code  of  many  services  may  not  be  available. 
Service  specification  will  be  extensively  used 
because  often  a  service  customer  has  access  to 
specification  and  URL  only,  no  source  code  or  even 
binary  code  would  be  available. 
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Differences  (continued) 


Traditional  IV&V  (OO) 

Service-Oriented  CV&V 

Definition 

By  independent  team 

Collaboration  among  multi-parties 

Approach 

Off-line  field  testing 

On-line  just-in-time  testing 

Regression 

Off-line  regression 

On-line  regression 

Integration 

Static  configuration  &  linking 

Dynamic  reconfiguration  &  binding 

Testing  coverage 

Structural  &  functional 

Specification&  Usage  based 

Profiling 

Static  and  centralized 

Dynamic  and  distributed 

Model  checking 

Based  source  code  or  states 

Just-in-time  dynamic  model  checking 

Reliability  model 

Input  domain  &  Reliability 
growth  models 

Dynamic  profiling  and  group  testing 

Certification 

Static  certification  center 

Dynamic  certification  based  on  history 
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Available  SO  A  System  Engineering 
Techniques 

■  Automated  completeness  and  consistency  checking. 

■  Verification  and  analysis  techniques  including  both  static  and 
dynamic  verification  techniques: 

■  Automated  state  model  generation; 

■  Formal  model  checking: 

■  Runtime  verification  and  constraint  checking  with  simulation; 

■  Automated  test  case  generation; 

■  Test  coverage  analysis  based  on  the  service  specification  and 
risk  analysis; 

■  Automated  dependency  identification  and  analysis; 

■  Automated  concurrency  analysis;  and 

■  Autonomous  distributed  test  execution  via  remote  agents. 
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What  is  a  Policy? 


■  A  policy  is  a  statement  of  the  intent  of  the  controller 
of  some  computing  resources,  specifying  how  he 
wants  them  to  be  used. 

□  Policies  are  ubiquitous  in  most,  if  not  all,  computing 
systems. 

□  However,  most  policies  implemented  are  hard  coded  into  a 
system  by  functional  requirements,  language  features,  and 
design  decisions. 

□  For  example,  if  a  policy  says,  “passwords  must  be  at  least 
8  characters  long”,  there  must  exist  a  segment  of  code  in 
the  system  that  checks  the  length  of  passwords. 
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What  is  a  Policy?  (Continued) 


■  A  policy  allows  or  denies  subjects  (such  as 
processes)  that  satisfy  some  conditions  to 
perform  designated  actions  on  objects  (such 
as  files). 

■  Policy, 

□  A  course  or  general  plan  of  action. 

□  A  contract  of  insurance  governing  a  plan  of  action. 

□  The  rules  or  constraints  governing  a  general  plan 
of  action. 
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What  is  a  Policy?  (Cont’d) 

■  The  common  pattern  of  a  policy  takes  the 
form  of: 


{allow  I  deny  |  require}  {subject}  performs  {action}  on  {object}  when  {conditions} 


Policy  specification,  enforcement  and 
revision  are  the  three  basic  mechanisms  a 
policy-handling  system  must  provide. 
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Limitations  of  Traditional  Policy 
Handling  Systems 

■  It  does  not  separate  policy  specification  from 
policy  implementation. 

■  Policies  are  difficult  and  expensive  to  change. 
Adding  new  policies  or  updating  /  removing 
existing  policies  requires  modifying  the 
policies,  recompiling  and  redeploying  these 
policies  into  the  system. 
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Benefits  of  Policy  Specification  Languages 
in  Enterprise  C2  (EC2) 

■  Policy  specification  languages  enable  policies  to  be 
defined,  independent  from  a  concrete  system 
implementation; 

■  Policy  specification  languages  are  to  be  interpreted 
by  a  policy  engine  at  runtime,  which  makes 
dynamical  policy  changes  possible; 

■  Policy  specification  languages  formalize  the  intent  of 
the  commander  into  a  form  that  can  be  analyzed 
and  interpreted  by  systems;  and 

■  Policy  specification  languages  are  high-level 
languages,  which  makes  it  easy  to  learn  and  use  by 
policy  makers  who  are  normally  non-programmers. 
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Policy-Based  Computing  in  GIG 


■  Policy-Based  Networking:  various  network 
operations  will  be  possible  but  they  will  be  controlled 
by  policies  in  an  EC2  SOA. 

■  Common  Open  Policy  Service:  this  is  a  query  and 
response  protocol  that  can  be  used  to  exchange 
policy  information  between  a  policy  server  and  its 
clients. 

■  Routing  Protocol  Specification  Language:  this 
allows  a  network  operator  to  specify  routing  policies 
at  various  levels. 

■  Internet  Protocol  (IP)  Security  Policy:  this  is  a 
repository-independent  information  model  for 
supporting  IP  security  policies. 
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Policy-based  Computing 


■  Each  computing  unit  has  a  formal  and  self  consistent  set  of  C2 
policies, 

■  It  has  a  set  of  C2  policy  execution  processes  (mechanisms), 

■  It  has  a  set  of  C2  process  performance  measures  and 
measurement  processes,  and 

■  It  has  an  accountability  structure  governing  allocation  of  assets 
required  in  and  consumed  by  the  execution  of  any  given  policy 
or  set  of  policies 

■  Each  policy  will  be  applicable  to  a  policy  domain.  The  EC2 
accountability  structure  defines  a  policy  tree  spanning  selected 
activities  of  the  joint  field  combatant  commanders  up  through 
the  President  of  the  United  States.  This  “nested”  set  of 
interdependent  policy  domains  constitutes  a  containment 
hierarchy.  Generally,  enterprise  policy  trees  include  high-level 
strategic,  mid-level  operational  and  low-level  tactical  policy 
domains. 
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Executable  Policies  in  EC2  SO  A 


■  A  policy  in  an  EC2  SOA  must  be  executable  as 
Dolicies  will  be  enforced  at  runtime  in  real  time,  and 
;hus  it  is  essential  policies  can  be  executed  at 
runtime  and  in  real  time  to  enforce  their  constraints. 

■  The  execution  capability  of  a  policy  language 
support  simulation  of  adding  or  modifying  policy 
prior  to  their  deployment  throughout  relevant  policy 
domains,  and 

■  Provide  a  formal  means  of  verification  and  validation 
that  policies  are  “correct”  with  respect  to  quality  of 
service  (QOS)  and  service  level  agreements  (SLA) 
established  for  their  respective  containment 
domains  at  runtime  and  in  real  time. 
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Policy  Enforcement  and  Operations 


A  policy  language  must  allow  policies  specified  to  be  enforced  either 
statically  or  at  runtime.  Both  static  and  runtime  policy  enforcement 
follows  a  3-step  process: 

■  Policy  C&C  checking:  This  ensures  that  policies  specified  are 
complete  with  external  requirements  and  regulations,  as  well  as 
consistent  with  each  other  before  application  of  these  policies  to 
evaluate  the  concerned  system.  Sample  security  policies  can  be 
Bell-LaPadular  security  policies  or  Chinese  Wall  security  policies; 

■  Embed  policies  with  the  system  specification:  Once  the  policies 
specified  are  determined  to  be  of  reasonable  quality,  the  policies 
specified  using  PSEL  can  now  be  embedded  into  the  system 
specification  for  evaluation;  and 

■  Evaluation  of  the  system  with  respect  to  policies  specified:  This 
step  evaluates  the  system  to  see  if  it  satisfies  the  policies 
specified. 
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Policy  Enforcement  and  Operations 
(Cont^d) 
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Different  Schools  of  Thoughts 


■  One  school  of  thought  (School  A): 

□  SOA  is  simply  an  implementation  technology  just  like 
programming  languages  or  design  techniques  such  as 
OOC; 

□  Emphasize  that  fundamental  C2  policies  remain  the  same, 
and  thus  focus  on  generic  EC2  architecture  independent  of 
implementation  technology. 

□  Policies  are  passive,  and  treated  as  static  XML  text  for 
constraint  checking  and  enforcement. 

□  Processes  used  to  enforce  policies  must  be  synchronized. 

□  Frequent  changes  in  policies  can  be  problematic,  and  thus 
policies  will  change  but  a  slower  pace.  Updating  policies 
may  involve  updating  related  processes  (services). 
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Different  Schools  of  Thoughts  (Cont’d) 


■  Another  school  of  thoughts  (School  B) 

□  Treat  policies  as  services  in  an  SOA.  In  other 
words,  policies  are  active  processes,  and  can  be 
published,  disseminated,  executed  and  monitored 
in  real  time  and  at  runtime. 

□  Change  of  policies  will  be  done  similar  to  change 
in  services  in  a  uniform  way.  The  SOA  already 
has  the  overhead  of  service  discovery  and 
execution,  and  this  overhead  can  be  used  to 
support  policy-based  computing. 

□  The  flexibility  and  adaptability  will  be  better. 
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Comparisons 


Policies  as  passive  objects  (School  A) 

Policies  as  active  services  (School  B) 

Policy  Specification 

Policies  specified  as  data  such  as  XML  files. 

Policies  specified  as  services 

Policy  Enforcement 

Policies  will  be  enforced  by  execution  services,  different 
enforcement  algorithms  and  software  can  be  used. 

Policy  services  are  active  services  that  can 
perform  enforcements.  Multiple 

services  may  cooperate  together  to 
accomplish  service  enforcement. 

Policy  Overhead 

As  policies  are  treated  as  static  objects,  the  overhead  of 
policy  is  the  overhead  of  accompanied 
computation  in  managing  and  enforcement  of 
policies. 

Policy  services  is  just  like  another  services. 
The  overhead  is  the  added  complexity 
of  activating  policy  services  while 
doing  regular  computing. 

Policy  Update 

Policy  can  be  updated  by  updating  the  related  policy 
files,  and  possibly  policy  processing  services  as 
well. 

Policy  can  be  updated  by  replaeing  the 
existing  policy  service  by  a  new  policy 
service. 

Policy  V&V 

Various  static  and  dynamic  V&V  mechanisms  can  be 
used,  e.g.,  completeness  and  consistency  checking, 
and  policy  simulation. 

Policy  V&V  will  be  equivalent  to  service 
V&V,  a  variety  of  static  and  dynamic 
V&V  techniques  can  be  used  including 
test  case  generation,  simulation,  and 
runtime  monitoring. 
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Comparison  (Cont’d) 


Policies  as  passive  objects  (School  A) 

Policies  as  active  services  (School  B) 

Policy  Simulation 

Policy  can  be  simulated  by  running  the  system  using 
policy  data. 

As  a  policy  service  is  just  another  service  in 
an  SOA,  policy  simulation  can  be  carried 
using  any  SOA  simulation. 

Policy  communication 

Two  systems  can  send  policies  to  each  other  like 
sending  a  regular  electronic  message  as  policies  are 
treated  as  data. 

Two  systems  can  communicate  their  policies 
by  sending  service  specifications  or  the  URL 
of  the  related  services. 

Policy  synchronization 

Policy  synchronization  is  needed  whenever  a  policy  is 
updated  or  the  system  is  reconfigured.  Formal 
synchronization  protocols  need  to  be  employed  to  ensure 
completeness  and  consistency. 

Policy  synchronization  is  needed  whenever  a 
policy  service  is  updated  or  system  is 
reconfigured.  Policy  services  may  actively 
pursue  their  own  service  synchronization 
protocols. 

System  Structure 

Enterprise  C2  systems  will  be  organized  in  an  SOA,  but 
policies  will  be  treated  as  objects  or  data  used  by 
services. 

Enterprise  C2  systems  will  be  organized  in 
an  SOA-manner  and  policy  services  will  be 
treated  like  a  regular  service. 

System 

Reconfiguration 

Systems  can  be  easily  reconfigured  using  a  DRS 
(dynamic  reconfiguration  service)  and  policy  files  need 
to  be  updated  to  ensure  that  new  policies  are  consistent 
with  the  new  system  structure. 

System  can  be  easily  reconfigured  using  a 
DRS,  and  policy  services  will  be  a  part  of 
reconfiguration  process. 
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Other  Consideration  Issues  and  Open  Issues 

The  EC2  SOA  still  face  many  open  problems  such  as: 

■  A  formal  yet  easy  to  use  policy  specification  language 
that  can  be  used  to  specify,  analyze,  simulate  and 
enforce  distributed  policies  in  an  EC2  SOA  federated 
systems; 

■  Distributed  policy  synchronization  and  enforcement; 
and 

■  Policy  dependency  analysis  to  assist  real-time  policy 
evolution; 

■  These  and  other  related  issues  must  be  addressed 
before  policy-based  computing  can  be  realized. 
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Demo 


■  A  network-centric  policy  enforcement  on  an 
embedded  system  is  available. 

■  This  is  to  demonstrate  that  it  is  possible  to  do 
real-time  code  generation,  dynamic 
reconfiguration,  verification,  policy 
specification,  policy  enforcement,  simulation 
at  runtime.  These  usually  take  days  if  not 
weeks  or  months  to  do,  now  they  can  be 
performed  on-the-fly  using  an  SOA 
technology  in  seconds  automatically. 
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Real-Time  and  Network-Centric  V&V 


Acceptable  Scenario 
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using  ACTOR  :ESSE_SAC 
using  ACTOR  :SOF_Team 

do  ACTION  ;SOF_Team.Vig3_A_Retreat 
do  ACTION ;  SOF_T ea  m .  V  ig3_A_L  leDown 

do  ACTION  :ESSE_SAC.Vig3_A_DetermineBestWeapon 
do  ACTION  ;ESSE_SAC.Vig3_A_CheckSOFTeamOutOfTari 
do  ACTION  ;ESSE_SAC,Vig3_A_Checl<SOFTeamLiedovi^ 

emit  EVENT  ;ESSE_SAC.Vig3_E10_IssueFireOrder 


SOF  Team  lies  down 
before  Fire  Order 
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No  policy  violation 
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15  vi g3^A_observeTar getstatus  changed  no  data  value 

15  Vi g3^ft^lnputTar getstatus  changed  no  data  value 

15  Vi g3^ft_ReadReportDestroyed  changed  no  data  value 
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Scenario  Violating  Policy 
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using  ACTOR  ;ESSE_SAC 
using  ACTOR  :SOF_Team 


do  ACTION ;  SOF_T ea  m .  V  ig3_A_Retr eat 
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do  ACTION  :ESSE_SAC.Vig3_A_DetermineBestWeapon 
do  ACTION  ;ESSE_SAC.Vig3_A_CheckSOFTeamOutOfTan 
do  ACTION  :ESSE_SAC.Vig3_A_CheckSOFTeamLiedo 

e  m  it  EVENT ;  ESSE_SAC .  V  ig3_E  lOJssueF  ireOrder 
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detected 


Vi g3_>_lnputTargetlnf o  chan^d  no  data  value 
vig3_A^5endTargetinfo  changed  no  data  value 
vi g3^A_ReadTargetinf o  ch^ged  no  data  value 
Vi g3_A_lssueCFFCommand  Ranged  no  data  value 
vig3^A_DetermineBestwe;apon  changed  no  data  value 
Vi g3_A_CheckSOFTeamOutOfTargetArea  changed  no  data  value 
vig3_A_checksoFTeam^edown  changed  no  data  value 
Policy  847  Failed. 

Vi g3_A_lssueFi reorder  changed  no  data  value 
vig3_A_MakeDecision  changed  no  data  value 
vig3^rL.VilleRejectMission  changed  no  data  value 
Vi g3_A_Mccl ai nissueFi reGunOr der  changed  no  data  value 
vig3^ft_0bserveTargetstatus  changed  no  data  value 
Vi g3_A_lnputTargetStatus  changed  no  data  value 
vig3_A^ReadReportDestroyed  changed  no  data  value 
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